home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20010921-20020314
/
000109_spcecdt@deeptht.armory.com_Sun Nov 4 18:15:01 EST 2001.msg
< prev
next >
Wrap
Text File
|
2002-03-13
|
2KB
|
51 lines
Article: 12927 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!panix!nycmny1-snh1.gtei.net!news.gtei.net!news-out.visi.com!hermes.visi.com!gemini.tycho.net.POSTED!not-for-mail
Newsgroups: comp.unix.sco.misc,comp.protocols.kermit.misc
Subject: Re: Dropping DTR in OSR5
References: <9s40rp$fdh$1@newsmaster.cc.columbia.edu>
Organization: The Armory
X-Newsreader: trn 4.0-test69 (20 September 1998)
From: spcecdt@deeptht.armory.com (John DuBois)
Date: 04 Nov 2001 22:51:20 GMT
Lines: 34
Message-ID: <3be5c667$0$439$8eec23a@newsreader.tycho.net>
NNTP-Posting-Host: 86058607.newsreader.tycho.net
X-Trace: 1004914280 gemini.tycho.net 439 spcecdt@192.122.209.42
X-Complaints-To: abuse@tycho.net
Xref: newsmaster.cc.columbia.edu comp.unix.sco.misc:139883 comp.protocols.kermit.misc:12927
In article <9s40rp$fdh$1@newsmaster.cc.columbia.edu>,
Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
>But the real problem is that when Kermit *does* try to drop DTR briefly,
>it never comes back on. So I need to ask: What is the way to turn off
>DTR and then turn it back on in OSR5? Currently I am using the POSIX
>way:
>
> cfgetospeed() and cfgetispeed() to get the speeds.
> cfsetospeed() and cfsetispeed() to set the speed to 0.
> tcsetattr() to make the speed changes take effect.
> (pause)
> cfsetospeed() and cfsetispeed() to restore the original speeds.
> tcsetattr() to make the speed changes take effect.
>
>The same code works fine on Linux, FreeBSD, and other platforms that use
>POSIX APIs. It appears to work fine in OSR5 too: the steps before the
>pause actually do work. But the steps after the pause, although they
>return no error indication and do not set errno, do not in fact make DTR
>and RTS come back on (as shown by the modem lights and the failure of the
>modem to respond to further commands).
Some problems in this area were fixed in 5.0.6a. Please test on that release
and see if you still encounter this problem.
>Speaking of modem signals, how are we supposed to read them? The TIOCMGET
>ioctl() fails with error 22 ("invalid argument").
This is how I know you aren't using 5.0.6a :) TIOCMGET/TIOCMSET/etc. were
first implemented in the sio driver in that release. In earlier releases,
support for these ioctls was present only in certain 3rd party serial drivers.
John
--
John DuBois spcecdt@armory.com. KC6QKZ/AE http://www.armory.com./~spcecdt/